Traditionally, the development, deployment and subsequent customization cost of even moderately complex software is significantly high. One of the primary contributors to the high cost of software development is associated with lack of adequate documentation of customer requirements. Further, a requirement document typically includes functional and non-functional requirements (NFRs), respectively describing what the system needs to do and how it is to be achieved.
Since, the skills needed for identifying functional requirements are different than those needed for identifying architectural solutions, the requirement engineering exercise is often carried out by different teams in a project. For example, functional requirements are collected and documented by business analysts and domain experts. But the architectural solutions related to requirements are identified/suggested by technology experts. As a result, the knowledge bank for functional requirements, and architectural solutions are maintained separately.
However, this may not be as simple as it looks, for example, some functional requirements statements may carry an architectural impact. The kind of impact they may have on architecture is typically not explicitly stated in the functional requirement statement and may be difficult to identify from a given set of functional requirements. Furthermore, the business analysts, who are collecting functional requirements, may not have the requisite technical knowledge to infer and articulate the architectural impact from the functional requirements that they capture from customers. They may not be technically equipped to ask right questions to the customer to unearth the architectural impact.
Failure to identify and analyze architecturally significant functional requirements early in the life cycle of a project may result in costly rework at later stages of software development. For example, “ability to receive notification whenever transaction is made” is a functional requirement which carries an architectural impact. This functional requirement explicitly does not state the mode through which a notification is to be made i.e. email notification or real time notification with an ability to subscribe to topic of interest. If notification is to be made using email, a simple event-driven architecture would suffice. However, for real time notification with an ability to subscribe to topic of interest a different architecture (e.g.—publish-subscribe) is required. Thus, identifying the architecturally significant functional requirements from the pool of functional requirements is difficult.
Therefore, there is a need for a system that identifies the architecturally significant functional requirements and recommend probing questions and architectural solutions to unearth architectural impact.